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MKTHOD AND APPARATUS FOR RANDOM required. Consistency can be ensured by directing all 

UPDATE SYNCHRONIZATION AMONG updates to a primary eopy and employing appropriate con- 

MULTIPLE COMPUTING DEVICES currency control. 

The issue considered is also different from that in a client 

FIELD OP THE INVENTION 5 server environment. In a client server environment, although 

•llic present invcn.ioa rcla.es in general lo memory upda.- '"Vf"' **" f" y T'* uncon ° cc,c ?- il ,lw *> s has , a 

f r 11 . 1 iwuiviiiui/upuai specihe server 10 synchronize to. See for example, n L 

m B and more specifically .o update synchromzat.on among ,£ wc||> el al > .. Rc y plicated Documem Managemcn, ?n a 

muluple eompuung dev.ces In particular, devtccs which are Group Communication System", in Groupware: Software 

temporarily connected lo the network are update synchro- f or Computer-supported Cooperative Work, pp. 226-?T> 

nized with other devices which reside on the network. IEEE Computer Society, 1992. and K. Moore, "The Imus 

BACKGROUND OF THE INVENTION ™r" *°T T' A , CM SIGM0D , 95 

conference, pp. 427-428 on the replication approach in 

With the rapid advancement of semiconductor, storage Lotus Notes. In this approach, the lime of last modification 

and display technologies, hand held or mobile devices have 15 is kc P l wiln cacn record (or document) of a replica. Only the 

become increasing versatile and popular. A user may simul- records modified since the last synchronization are 

laneously posses several of these devices, such as Palm Pilot exchanged during the synchronization. Another approach as 

(which is a trademark of IBM Corporation, Armbnk, N.Y), uscd b y Pa,m pitel fe lo maintain a dirty bit on each modified 

mobile phone, laptop PC, home PC, office workstation, etc. rccord - Whcn a rccord * modified, the dirty bit is turned on. 

A single database, file or document may be multiply repli- ™ Durin £ synchronization, all modified records arc exchanged 

catcd over several of these computing devices. and lnc dirl y bits arc rcscl 10 zcro - Kor example, R. Riggs, 

A critical issue in this environment is that these multiple "MNCRS Data Synchronization Architecture Document", 

replicas on the various devices may be updated indepen- www o ad g k Or ; jp/aclivity/mncrs/dsync/arch/ 

dcntly. Furthermore, the update synchronization can occur daJ ^y^arch.html, specifies a framework for data synchro- 

between any pair of devices. Since many of these devices arc nwtion between mobile network computers, such as Palm 

mobile or hand held, they are only occasionally connected " 1 ^ , and or P° crs - 

cither to the network or directly to another device. Any ,n ,hc cnvironniC111 considered here, a device can request 
centralized scheduling on update synchronization will not sync Wlth 0,hcr dcvicc - 11,erc ,s 00 designated sync- 
work in this envirorncnt. Neither will the client-server scrvcr for a dcv,cc A straightforward approach to do any- 
model where each client machine will always perform J0 io ' m Y ^ ac ,s lo mainla,n a ! °cal lime-stamp on update by 
synchronization with a prc-assigncd scrvcr. Mere the appro- cach dcvicc on cach rccord » C S» device I updates record 1 
priatc model is the any-to-any synchronization model, where al 9:50 am ' Jun " 23 ' 1997 and dcvicc 2 "Plates the same 
any pair of devices can perform synchronization with each rccord at 10:50 am * Jun ' 25 ' ,997 ' Sincc ,hc u P da,c limc is 
other at any time. Por example, assume an individual has ba * ed on Iocal dcv,cc Ul ™» no S ,ubal limc synchronization 
four devices: Palm Pilot, Thinkpad (which is a trademark of 35 would bc rct l uircd - nic problem with this time-stamp 
IBM Corporation, Armonk, N.Y.), office workstation and * "PP™"* » mat me number of hits required to represent the 
desktop PC at home. Ine individual may want to replicate hme-stamp is sizable. For example, a lime stamp with 
his calendar over all of these devices. On a business trip, he year/monlh/date/tiine can require more than 32 bits. As the 
may bring the Palm Pilot and Thinkpad with him. He can numbcr of rccords a,ld dcv,ccs '"creases, il will cause 
leave the lliinkpad in the hotel and only carry the Palm Pilot 40 considerable delay to perform the synchronization, espe- 
to his business meeting. When returning lo the hotel, he can cia,ly 111 a low bandwiJ,h environment such as a phone line, 
synchronize the Thinkpad with the Palm Pilot which con- An alternative approach is the local counter approach that 
tains the update he had made during the day. The individual maintains a local counter on each device, where every limc 
can then use the Thinkpad to dial up to the office workstation a rccord of a database (or file) is updated (or inserted/ 
to synchronize wiih the update made by his secretary on the 45 deleted) by a device, the local counter for the device which 
workstation copy. Mis wife at home can synchronize ihc performed the update is incremented by one, and assigned lo 
copy on the home PC with the office workstation so she can lhal nic as a version number. For example, I). S, Parker, et 
let him know the weekend schedule. al » "detection of Mutual Inconsistency in Distributed 
litis update synchronization issue is different from the i*)??™" !P J"™" 0n Soflwarc Engineering, Vol. 
conventional database update issue among multiple replica 50 , ' ' May 1983, pp. 240-247, provides a means to 
where most of the devices are always connected, IIk Select version conflict through maintaining the version num- 
stanclarcl transactional approach is to propagate every update hcrs , Fmm cach sys,cm or (,CVICC ln a r,,c l1lis vcrsion 
to all replica before a transaction can commit. This is nUmhcf Can 81,11 bcComc an arbi,raril y number, 
described, for example, in P. A. Berstein, et al., "Concur- SUMMARY OF Till: INVENTION 
rency Control and Recovery in ^lahase Systems", 55 A computing device has a databa.se replica comprised of 
Add-on- Wesley Reading, Mass. 1 987. Fhis update or a |ura|i( of rccords A synchronizalion 1 ^ is fovidcd 
write-all approach can use any senahzable concurrency l0 a fur|hcf compuling dcvice havj , |ur(hcr Cubase 
control to synchronize access to the multiple copies. A rcp | ica which Ls comprised of a further plurality of records, 
variation ,s to allow for only updating a majority of the A vcrsion |ibk maimajns for cach ()f Jhc 
replica or quorum consensus. Another variation ,s the lazy ,0 , ura|il of fcC()rds ^ VCfsion numbcfS cach havc 
propagation approach where only one rephca is updated by maximum si/c ^ maximum sj/c js sc|cclab|c . |u . 
he tran.sact.on ..sell as tor example Y Brcitbart, et a!., ralit of rccords ma hc synchronizcd wilh , hc (uf \ h „ 
Replication and Consistency: Being Lazy Helps , ura|il of M (|mj vcrsjun nuirfj| . 
Sometimes , Proc. AC M Symposium on Principles of Data- 
base Systems, 1997, pp. 173- 184. In this approach, a 65 HRIliP DLSCRIPIION OF Till: DRAWINGS 
separate transaction runs on behalf of ihc original transac- Fid. I Ls a block diagram which depicts an example of an 
lion at each replication site at which update propagation is overall architecture of a computing device. 
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FIGS. 2(a), 2(b) and 2(c) depict examples of version Past updalc activities arc tracked so that independent 

tables which contain update information for exchange dur- updates from the different devices to the different replica of 

ing synchronization to identify for each record which device the same database can be consolidated. This is described 

has the more up-to-date version of that record. below. 

RG. 3 is a llowchart diagram which illustrates exemplary 5 Consider the following example. Device 1 creates a 

execution of computing device logic. database with 5 records. Then, devices 2 and 3 obtain a copy 

FIG. 4 Is a flowchart diagram which illustrates exemplary of that database from device 1. Afterwards, device I makes 

operation of the sync initiator. an update to record 1, and three updates to record 2. Device 

FIG. 5 is a flowchart diagram which illustrates exemplary 2 makes an update to record 3 and device 3 makes an update 

operation of the sync handler. 10 lo record 5. Device 4 then gets a copy of the database from 

FIG. 6 is a flowchart diagram which illustrates exemplary device 3 and raakcs an u P datc 10 rccord 4 - Now » dcvicc * 

execution of the version comparison routine. * requests synchronization with device 1. The issue is which 

FIG. 7 is a flowchart diagram which illustrates exemplary [! CvicCS h * VC th ^ m ° rc "P" 10 ^* of each rccord. In 

execution of the update sync routine. ,< L c j^' d ^ v 1 ,cc J 4 h . as morc u P- to - da * v *™on of records 

rtr- o • n u_.j- L -u-.. , 4 and 5 » wn, * c device 1 has the more up-to-date version of 

JSil J 7£ WH,Ch ' ,,u * ra,escxcm P ,ar y records 1 and 2. So during the synchronization, device 1 

operation of a replica initiator. nccds lQ upda|c rccords ^ ^ • ^ {q 

FIG. 9 is a flowchart diagram which illustrates exemplary update records 1 and 2. 

operation of a replica handler. ~ . , , , - 

np in . ' . » . L - L ... ™ Consider another case where device 3 requests syuchro- 

FIG. 10 is a flowchart diagram which illustrates exem- 20 m>aIion wiJh devicc , Man dcvjcc 4 D {hc ^ 

plary operation of a rccord modifier. nization bcXwwn tleviccs j and 3f dcvicc j WQu|d nccd {Q 

FIG. 11 is a flowchart diagram which illustrates a garbage update rccord 5, and device 3 would need to update records 

collection routine. 1 an( j 2. When device 4 requests synchronization with 

FIG. 12 is a flowchart diagram which illustrates a local device 1 later, device I only needs to update record 4 in 

marked routine. 25 contrast to the original case. Device 4 still needs to update 

FIG. 13 is a flowchart diagram which illustrates an records 1 and 2. 

example of a phase one advancement checking routine. A third case will be that continuing from the second case, 

FIG. 14 is a flowchart diagram which illustrates an device 4 requests synchronization with device 2 before it 

example of a phase two advancement checking routine. w requests sync with device 1. During sync between devices 4 

FIG. 15 is a flowchart diagram which illustrates an and 2 ' dcvicc 4 u P datcs rccord 3 and device 2 updates 

example of a remote mark routine, records 4 and 5. On the subsequent sync between devices 4 

and I , devicc 4 nccds to update records 1 and 2, while device 

D1£TA1LI£D DliSCWHON OF 1U1£ 1 needs to update records 3 and 4. 

INVEN HON ^ p mm lhc abovc cxamp j eSf j t can bCj mat in ordcr |0 

It is desirable to use a compact version number per device perform the synchronization correctly, one must know what 
for each record which lakes just a few bits (say 2 or 4) to updates from each of the devices arc captured in each rccord. 
represent the version of the rccord, while allowing for FIGS. 2(a), 2(b) and 2(c) depict examples of version 
multiple computing deviccs to maintain replica of data tables which contain the updalc information for exchange 
objects and perform updates independent of the other rep- 40 during synchronization lo identify for each record which 
lica. The synchronization with oihcr replica is desirably device has the more up-to-date version of that rccord. Fach 
carried out in any arbitrary ordcr efficiently (i.e., with low database has a version table and each of its records has an 
bandwidth requirement) in a pair-wise fashion as these entry in the version table. 'Die entry consists of two parts, 
devices are most disconnected from each other. This com- Hie first part is the record ID and ihe second part is the 
pact representation can reduce Ihe bandwidth requirement 45 version list. 'Hie version list includes a device-version coin- 
substantially by an order of magnitude. ponenl for each device with a replica of the database. Il has 

FIG. 1 is a block diagram which depicts an example of an lhc form of ((dl, vl), (d2, v2), . . . , (dk, vk)), where dk 

overall architecture of a computing device, "llic computing represents lhc i-th devicc ID and its version number vi. 'Hie 

device can be, for example, a PC, a hand held device (such number of bits required to represent the version number 

as a Palm Pilot, a smart phone, etc.), a workstation (such as 50 decides lhc size of the versinn tabic. Since the content of the 

RS60U0), etc. version table is communicated during synchronization, a 

Die computing devicc can include a CPU 150, memory method is provided (hat can use a compact version number 

145 such as UAM, and storage devices 160 such as DASD. which consists of only a small number of maximum bits, say 

The memory 145 stores lhc client logic 140 (with details 2 lo 4 bits. This number (or inlcger) can be sjjccified by the 

depicted in FIG. 2) preferably embodied as computer 55 user or syslcm administrator. 

executable code which may be loaded from DASD 160 into As shown in FIG. I, version manager 350 is included, 

memory 145 for execution by CPU 150. Many hand held Version number manager 350 includes logic which may be 

devices store all information in memory without any storage invoked, for example, by the user or system administrator, 

devices. 'Die computing device logic 140 includes a sync Version number manager 350 accomplishes configuration of 

initiator 320 (with details depicted in FIG. 4), a sync handler 00 the size of the compact version number. The size of the 

330 (with details depicted in FIG. 5), a replica initiator 335 compact version number may be separately configured for 

(with details depicted in FIG. 8), a replica handler 340 (wilh each computing device thai is being used. For example, 

details depicted in FIG. 9), a record modifier 315 (with devices thai do not have a large memory (e.g., a Palm Pilot) 

delaiLs depicted in FIG. 10) and a version number manager may be set lo have a compact version number wilh a size of, 

(described below), li also maintains a version table 180 and os for example, 2 lo A bits. By contrast, large devices (such as| 

a database 170 which can cither reside in disk 160 or in main for example, PCs) may be configured lo have compact 

memory 145. version numbers wilh a large size (e.g., 4 bytes). 
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The compact version number is used lo track updates onto the two replicas arc in conflict, i.e., both devices have made 

a particular record. The compact version number does not updates to the same record. In that case, the sync handler 

reflect updates to other records. For example, the compact routine only identifies the record in conflict. The conflict 

version number, vi, is incremented by one each time the resolution is resolved at the application level, l or example, 

record Is updated by the i-lh device, di. Since the compact 5 consider a calendar application. If the very same event gels 

version number only consists of a few number of bits, for the rescheduled in two different time slots via two different 

often updated records, their compact version numbers can devices (presumably by two different persons), the sync 

overflow and a method is provided to address this issue in server desirably flags the two conflicting records and lets the 

the record modify routine depicted in FIG. 10. uscr or application resolve the conflict. If there is no conflict, 

Since each device can independently insert a new record, J(J the sync handler 330 uses the version list to determine which 

the record ID consists of two components the device ID copy or version of a record is the up-to-date version to 

creating the record and a unique sequence number assigned rep iace the other copy of the record. The sync handler 330 

to that dcvjce. For example, record (2.1) represents the first crcates tnrce separate lists of records: send-list, receive-list 

record created by device 2 and record (1 .5) represents the 5'" and conflict-list. Scnd-lisl includes the record IDs of those 

record created by device I. Certainly, as the number of rccords wncrc lnc | oca , devicc has , hc morc up . l0 . dalc 

devices having a replica changes over time, the number of version, while the receive-list includes the record IDs of 

components in the version list also changes accordingly. tnosc rccords whcrc lhe rcmolc dcvicc nas lhc morc up . lo . 

When a device inserts a new record, that record is given date version. The conflict list includes the record IDs of 

a version number of 1 . When a device simply receives (for those rccords where the local and remote devices have made 

the first time) a replication of a record, the receiving device conflicting updates. 

gives the newly received record a version number of 0. " FIG. 4 is a flowchart diagram which illustrates exemplary 
Consider an example. Start with device 1 which creates a operation of the sync initiator 320. At step 405. the corn- 
database with two rccords, record 1.1 and record 1.2. Their puting device initiating the sync sends the sync request 
version numbers are all ( 1 ,1 ) as shown in FIG. 2(a). Now, together with the version table of the database to the target 
device 2 comes and requests a replica. The version list will 25 dc vicc. It then wails for the response at step 410. When the 
now become ((1,1 )(2,0)) for both devices, as shown in FIG. response arrives, it checks at step 415 whether the scnd-lisl 
2(b). If device 2 inserts a new record, il will have a record is non-empty. If so, at step 420, for each record ID in the 
II) (2.1) and version list ((1,0X2,1)). If it updates record scnd-lisl, it updates the record value and its version list. At 
(1.2), the record will have a new version number ((1,1)(2, step 425, il checks whether the rcccivc-lisi or conflict-list is 
1)). If device I updates record (1.1), it will have a new 30 non-empty. If so, at sicp 430, it sends all records indicated 
version number (( 1 ,2)(2,0)). If it inserts a new record, lhe on lhc rcccivc-list and conflict-list to the target dcvicc. At 
record will have an ID (1.3) and a version number ((1.1) step 435, il checks if the conflict-list is non-empty. If so, at 
(2.0)). If the two devices sync with each other, the resulting stop 440, il will invoke the conflict handler routine which, as 
version is shown in FIG. 2(c). mentioned before, is only recording the conflict for the 

Thosc skilled in the art will also appreciate that there arc 35 application to resolve the conflict, 

different ways to represent" the record ID. One alternative FIG. 5 is a flowchart diagram which illustrates exemplary 

implementation is not to directly include the device ID in the operation of the sync handler 330. At step 505, the target 

record ID, but to use separate tables or table partition lo device receives the sync request with the version lable of the 

represent lhc records crcaicd from each dcvicc. Similarly, database. It then examines each of the record IDs indicated 

there are many alternative ways to implement the version 40 in either the local version lable or the remote (requesting 

list. One optimization is to eliminalc all devices which have device) version tables. At step 510, if there is no more 

not yet made any updates lo a record from its version list. unexamined record IDs in either version tables, the update 

That is to say, in FIG. 2(6), lhc version list for (1,1) is now S ync routine in WO. 7 is invoked at step 550. Otherwise, at 

reduced to ( 1 , 1 ). Another alternative is not lo keep the device step 5 15, lhe next not yet examined record in the two version 

ID in lhc list, bui to keep a table-wise order on the devices. 45 lables is selected. At step 520, it is checked if the selected 

For example, if lhc table -wise order on the devices is (device record ID appeared in boih version tables. If so, at step 525, 

I, device 2, device 3), then a morc compact representation ihe version comparison routine in FIG. 6 is invoked, 

of the version list ( 1 ,1 )(2, 1 )(3,0) is ( 1 ,1 ,0). Also, if a device Otherwise, at step 535, it is checked if the selected record ID 

has not yel made any update to any of the rccords, it can also appeared only in the local version table. If so, ai step 540, 

be omiltcd from the version lisl. 50 the record ID and its version llsl is added to lhe scnd-lisl. 

FIG. 3 is a flowchart diagram which illustrates exemplary Otherwise, lhe record ID only appears in the remote version 

execution of computing devicc logic 140. In step 305, the table. At step 545, the record ID and its version list is added 

device waits for input. Depending upon the lype of input, the lo the receive-list. 

appropriate routine will be invoked. The sync initiator 320 FIG. 6 is a flowchart diagram which illustrates exemplary 
is used to request database (or any data object) synehroni- 55 execution of the version comparison routine in FIG. 5. At 
zation with another computing device. Hie sync handler 330 step 605, the local version number and lhe remote version 
handles the sync request from another device lo synchronize number on every device are compared. If the devices 
the two replica. Itic replica initiator 335 is used lo request included on the two version lists are noi the same, each 
a replica of a database which the device does not yet have version lisl will be augmented to include the missing devices 
a copy, white the replica handler 340 is to provide lhe 6 o with the version number set to zero during the comparison, 
requesting device with a copy of the database. ITie record The local version table can be immediately updated, while 
modifier 315 is used to handle the database modificalion of the device IDs of the missing devices form the remote 
the local replica which can be a record update, deletion or version table can be included in the scnd-lisl for the request- 
insertion. A feaiure of the record modifier 315 is the way il ing devicc to update its version table later. If the version 
updates lhe version list of the modifier record. 65 number is not Ihe same on every devicc, it is further 
Hie sync handler 330 handles Ihe sync request basal on checked, at step 610, if the local version number is larger 
the version lists to determine whether versions of a record in than or equal lo the remote version number for every device. 
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If so, at step 620, the record ID and its version list arc added 
to the send-list. If so, at step 615, it is checked whether the 
local version number is smaller than or equal to the remove 
version number for each device. If so, at step 630, the record 
ID and its version list arc added to the rcccive-list. 
Otherwise, at step 625, the record ID and its version list arc 
added to the conflict-list. 

FIG. 7 is a flowchart diagram which illustrates exemplary 
execution of the update sync routine in FIG. 5. At step 705, 
it is checked whether the send-ILst or conflict -list is non- 
empty. If so, at step 710, the nonempty send-list and 
conflict-list will be augmented with the corresponding 
record for each record ID in the lists to be sent to the 
requesting device. At step 715, it Is checked whether the 
receive-list is non-empty. If so, at step 725, the rcccive-list 
is sent to the requesting device. At step 730, the target device 
wails for the response from the requesting device. At step 
720, if the conflict-list is non-empty, execution proceeds to 
step 730 to wait for the response. Upon receiving the 
response, at step 740, for each record ID in the receive-list, 
the record and its version list get updated. At step 745, if the 
conflict-list is non-empty, the conflict handler routine is 
invoked at step 750. As will be explained later with refer- 
ence to FIG. 12, at step 760, the garbage collection routine 
can be invoked to clean up the space occupied by deleted 
records. 

FIG. 8 is a flowchart diagram which illustrates exemplary 
operation of replica initiator 335. Al step 805, a computing 
device sends a replica request of a database to a target 
device. At step 810, the computing device waits for the 
response. Al step 820, the computing device receives the 
database replica and its version table. 

FIG. 9 is a flowchart diagram which illustrates exemplary 
operation of replica handler 340. At step 910, the device 
receives a new replica request for a database. Al step 920, 
ihc device updates the version table by adding to the version 
list of each record an additional component (dk, vk), where 
dk is the device ID of the requesting device, and vk is set to 
zero. Al sicp 910, Ihc database and its version table are sent 
to the requesting device. 

FIG. 10 is a flowchart diagram which illustrates exem- 
plary operation of the record modifier 315. There are, for 
example, three different ways to modify a database: updale 
a record, delete a record and insert a new record. Al step 
1005, it is checked if ihe database modification request is to 
update a record. If so, at step 1010, the record value is 
updated. Al step 1015, the version number associated with 
Ihe local device is incremented by 1 (for example). At step 
1020, it is checked for overflow, i.e., if the version number 
exceeds iis maximum allowed value (e.g., if 4 bits are 
allocated to represent Ihe version number, the maxim uni 
allowed value will be 15). If so, an overflow method (steps 
1025 and 1030) Is invoked. At step 1025, a new record is 
created with a new record II) and the same record value as 
the updated record. Hie version list will be Ihe same as the 
updated record except thai Ihe version number is sel to zero 
for the target device. Al step 1030, the original record is 
marked as a deleted record. Al step 1035, it is checked if the 
database modification requesl is to delete a record. If so, al 
step 1040, ihe record is marked as a delclcd record. 
Otherwise, the requesl is a record insertion. At step 1060, a 
new record is inserted inio ihe database with a version list 
created in ihe version (able. Ihe version number on each 
device is initialized lo zero except for the local device which 
is sel lo one. 

"loose skilled in the an will also appreciate that there are 
alternative ways to increment the compact version number 
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upon updates. An alternative mclhod is to have ihc version 
number only capture the number of sync intervals with 
updates lo Ihe corresponding record, iaslcad of the number 
of updates lo the record, where a sync interval is the lime 
5 interval between two consecutive sync poinls (lo any 
devices). That is lo say under this alternative mclhod, 
multiple updates wilhin a single sync interval by a device 
will only cause the version number lo he incremented by 1. 
Only the first update to a record since the last synchronize - 
1(J lion will cause the version number (associated with the local 
device) lo increase. This would reduce Ihe number of times 
a version number exceeds its maximum value. 

Because each device can modify any records 
independently, the version list of a deleted record is desir- 
, 5 ably kept after the record deletion. Otherwise, it would not 
be able to differentiate during synchronization whether the 
olhcr device has an older version or the deleted record or 
conflicting version of Ihc deleted record. 
To eliminate storage waste, garbage collection can be 
20 done to recover storage occupied by records thai have been 
marked for deletion. In the preferred embodiment, a mclhod 
is provided using a three phase deletion protocol. The record 
deletion protocol uses two vectors for bookkeeping. A phase 

1 vector is a bit vector to track the devices thai have been 
25 notified on the record deletion. At ihc end of phase 1, every 

device with a copy of the database has been notified that the 
record is marked for deletion. A phase 2 vector is a bit vector 
to track the devices thai arc aware of the fad that all devices 
with a copy of the database have been notified that the said 

30 record is marked for deletion. All devices will have deleted 
both the version list of the record and the phase 1 vector by 
the end of phase 2. In phase 3, the devices can now delete 
the phase 2 vector. For a device in phase 3 on a deleted 
record, there is no longer any bookkeeping (such as phase 1 

j 5 or phase 2 vector) maintained on the deleted record. All 
storage space is recovered on the said device for that record. 
By ihe end of phase 3, ihe phase 2 vector of the record is 
deleted from all devices. 

Those skilled in the art will also appreciate that alternative 

40 ways can be used to implement the phase I and phase 2 
vectors. In the preferred embodiment, Ihe phase 1 and phase 

2 vectors are considered to be part of the version lable in 
FIG. 2. In addition to ihe two columns in Ihe version table, 
a third column can be added to include a pointer lo ihe phase 

45 1 or phase 2 vector. One pointer suffices as a record can only 
be in phase 1 or phase 2 and at any given time, at mosl one 
of the vectors is needed. Allcrn a lively, a separate deletion 
list can be maintained for all records marked for deletion 
with a pointer to their phase 1 or phase 2 lists. 

50 In the preferred embodiment, after a record is marked for 
deletion, a phase I vector is desirably created. This step is 
desirably added to steps 1030 and 1040 depicted in FIG. 10 
after the record has been marked for deletion. Ihe record 
itself can in fact be deleted hut its version list is desirably 

55 kept. During subsequent sync, the phase I vector is copied 
lo other devices with Ihe bit corresponding to the already 
notified devices turned on. When the last known device with 
a copy of Ihe database gets notified on the deletion during 
the sync operation, the two synchronizing devices can 

oo actually delete their phase I vectors, create the phase 2 
vectors (with the bits corresponding to the two devices 
turned on) and enter into phase 2. During phase 2, a device 
checks whether any new replica has been created during 
phase 1. If so, it adds the new device lo ihe list of devices 

o5 on the phase 2 vector. During phase 1, if a new device 
requests a replica from a device which already marked the 
record for deletion with an associated phase I vector, the 
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new replica will also indicate ihc record is marked for 
delelion with an appropriate phase 1 vector created. Thus, 
even if a new replica created during phase 1 may not be 
included in the phase 1 vector of some of the devices, it docs 
not pose a problem. 

Consider an example with three devices. After device 1 
has sync with device 2, a new device, device 4, requests a 
replica from device I. Device 2 then requests sync with 
device 3. The two devices, not being aware of the existence 
of device 4, will enter into phase 2. Since device 4 also 
marks the record as deleted, the condition for entering into 
phase 2 Ls still satisfied. Unfortunately, the phase 1 vector of 
some of the devices may only indicate 3 devices. This will 
be addressed during phase 2. During phase 2, when the other 
device (say device 2) has sync with device i, it will find out 
that an additional device has obtained a replica and augment 
its phase 2 vector. Thus, replica creation during phase I does 
not pose a problem. Similarly, during phase 2, the device 
with a new replica is also desirably included in the deleting 
process. During phase 2, if a new device makes a request for 
a replica, the new replica will also include information on 
the deleted record, specifically the phase 2 vector. 

During phase 2, synchronization will lead to the synchro- 
nizing devices deleting the phase 1 vector and updating the 
phase 2 vector. When all the devices have gone through 
phase 2, the phase 2 vectors can be deleted. For a device with 
a partially specified phase 2 vector, it will delete the vector 
and enter into phase 3 during sync, if the other device has 
neither the phase 1 nor the phase 2 vector for that record. If 
the other device has a phase 1 vector for the record, that 
device will enter into phase 2 and the phase 2 vectors of both 
devices get updated to reflect the change. If the other device 
has a phase 2 vector, both devices should update their phase 
2 vectors to be the union of the two, 

FIG. II is a flowchart diagram which illustrates the 
garbage collection routine of HO. 7. At step 1105, all 
records that have been marked for deletion in the local 
version table are identified. For each of these records, at step 
11 JO, the local marked routine depicted in details in FIG. 12 
is invoked. At step 1120, all records that have been marked 
for delelion in the remote version table are identified. For 
each of these records, at step 1125, the remote marked 
routine depicted in details in FIG. 13 is invoked. At step 
1 140, the phase 1 and phase 2 vectors that need to be updated 
(by the remote device) are sent to the remote device. When 
the remote device receives the updated phase 1 and phase 
vectors, it will update its phase 1 and phase 2 vectors 
accordingly. 

FIG. 12 is a flowchart diagram which illustrates the local 
marked routine. At step 1205, it is checked if the record is 
considered to be in phase I by the local device. If so, at step 
1210, it is checked whether the record is considered to be in 
phase 2 by the remote device. If so, at step 1215, the phase 

1 vector is deleted and a phase 2 vector is created for the 
record in the local device. 'ITiis is to recognize that the 
deleted record is now in phase 2. This newly created phase 

2 vector will be the same as the remote phase 2 vector for 
that record with the exception that the bit position corre- 
sponding to this device will not Ix turned on. At step 1220, 
the phase 2 advancement checking routine depicted in FIG. 
14 is invoked. At step 1225, the phase I vector for the local 
device is updated. Specifically, if the remote device is in 
phase I , the new phase I vector is not the union of the phase 
I vectors of the two devices. If the remote device has not 
marked the record for deletion, the bit corresponding to the 
remote device is now turned on in phase I vector. 'ITie 
exception Ls that if the remote version list is in conflict with 
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the local version list, it Ls addressed in step 625. At slcp 
1230, the phase 1 advancement checking routine depicted in 
FIG. 13 is invoked. At step 1240, it is checked whether the 
record is considered to be in cither phase 1 or phase 2 in the 

5 remote device, while it is considered to be in phase 2 in the 
local drive. If so, at step 1245, the phase 2 vector is updated. 
If the record is also in phase 2 in the remote device, the new 
phase 2 vector will be the union of Ihc two phase 2 vectors 
of the local and remote devices. Otherwise, it will be the 
local phase 2 vector with the additional bit corresponding to 
the remote device turned on. At slcp 1250, the phase 2 
advancement checking routine is invoked. At step 1260, the 
phase 2 vector is deleted. This corresponds to entering the 
third phase of the record deletion process as the remote 

is device is already in phase 3. 

FIG. 13 is a flowchart diagram which illustrates an 
example of the phase 1 advancement checking routine of 
FIG. 12. At step 1305, it is checked whether all devices have 
their corresponding bits turned on in the phase 1 vector of 

2Q the record. If so, at step 1310, the phase 1 vector Ls deleted. 
The deletion process of the record now enters into phase 2. 
At step 1310, a phase 2 vector is created for the record with 
the bits corresponding to the two synchronizing devices 
turned on. 

25 FIG. 14 is a flowchart diagram which illustrates an 
example of the phase 2 advancement checking routine in 
FIG. 12. At step 1410, it Ls checked whether all devices have 
their corresponding bits turned on in the phase 2 vector of 
the record. If so, at step 1420, the phase 2 vector is deleted. 

}q The delelion operation of the record now enters inlo phase 
3. 

FIG. 15 is a flowchart diagram which illastratcs an 
example of the remote marked routine. At step 1505, it is 
checked if that record Ls in phase 1 of the deletion process 

35 at the remote requesting device. If so, this corresponds to the 
case lhal while a record is in phase I of the deletion process 
at the remote requesting device, it is not yel marked as a 
deleted record in the local device. Al step 1510, a phase 1 
vector with an additional bit corresponding to the local 

40 device turns on. An exception is that if the remote version 
list is in conflict with the local version list, it is addressed in 
step 625. Al step 1520, the phase 1 advancement checking 
routine in FIG. 13 Ls invoked. It is noted that at step 1505, 
if the record is in phase 2 at the remote site, it means lhal the 

45 local site is already entered inlo phase 3 with the phase 2 
vector deleted. No further step needs to be done al the local 
site. Hie remote site would need to delete the phase 2 vector 
to enter inlo phase 3 when it received all the updated phase 
1 and phase 2 vectors for all deleted records from the local 

50 device. 

Those skilled in Ihc arl will also appreciate (hut although 
the preferred embodiment of ihe present invention only has 
ihc version ILst attached to each record, the approach can be 
straightforwardly generalized to a hierarchical approach of 

55 attaching a version ILst to the whole database or a partition 
of the database. Ilie advantage of the hierarchical approach 
Ls as follows. First of all, it can save the amount of 
information exchange, or the communication bandwidth 
requirement. Al sync time, the sync initiator will is send Ihe 

60 version list of the database (instead of the version lable) lo 
the target server. If the Iwo version ILsts of the database are 
the same, the two databases are in sync. No further exchange 
of information is required. Otherwise, I lie version lable of 
the requesling device is desirably sent lo the larget device as 

o5 before. 

Although the invention is illustrated and described herein 
with reference to specific embodiments, the invention is not 
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intended to be limited to the details shown. Rather, various 
modifications may be made in the details within the scope 
and range of equivalents of the claims and without departing 
from the invention. 

What is claimed is: 5 

1. A method of synchronizing a plurality of computing 
devices each containing respective database replicas, each of 
said replicas having respective records, said method com- ' 
prising the steps of: 

a) configuring a maximum size, in bits, for a version 0 
number, said maximum size separately configurable for 
each of said computing devices; 

b) maintaining, for each of said computing devices, said 
version numbers for each of said respective records, 
said version numbers having said maximum size; 

c) transmitting a synchronization request between said 
computing devices; and 

d) synchronizing said computing devices so that said 
respective data base replicas have common records 
based upon said version numbers respectively main- 
tained for said computing devices. 20 

2. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein said version numbers 
for a first of said computing devices is maintained in a first 
list and said version numbers for a second of said computing 
devices is maintained in a second list. 25 

3. A method of synchronizing a plurality of computing 
devices according to claim 2, wherein said first list and said 
second list indicate respective records which correspond and 
arc different versioas, and, during synchronizing, at least one 

of said first of said computing devices and said second of jo 
said computing devices arc updated so that the first of said 
computing devices and the second of said computing 
devices have respective records which correspond and have 
the same versions. 

4. A method of synchronizing a plurality of computing 35 
devices according to claim 2, wherein during synchronizing 

at least one of said first list and said second list are updated 
so that said first list and said second list indicate respective 
records which correspond to each other. 

5. A method of synchronizing a plurality of computing 
devices according to claim I, wherein a respective one of 40 
said version numbers is incremented when a respective one 

of said devices updates a respective one of said records. 

6. A method of synchronizing a plurality of computing 
devices according to claim 2, wherein during synchronizing, 
one of said records is deleted from one of said first of said 45 
computing devices and said second of said computing 
devices so that the first of said computing devices and the 
second of said computing devices have the same corre- 
sponding records. 

7. A method of synchronizing a plurality of computing 50 
devices according to claim 6, wherein storage space occu- 
pied by said deleted one of said records is subjected to 
garbage collection. 

8. A method of synchronizing a plurality of computing 
devices according to claim 7, wherein if said respective one 55 
of said version numbers is incremented to a maximum value, 
then a new record is created and said respective one of said 
records is deleted. 

9. A method of synchronizing a plurality of computing 
devices according to claim I, wherein one of said version 60 
numbers is incremented by a fixed increment regardless of 
number of updates to said record corresponding to said one 

of said version numbers between successive synchroniza- 
tions to said computing device having said record. 

10. A method of synchronizing a plurality of computing os 
devices according to claim 1, wherein a respective further 
version number is assigned each of said database replicas. 



11. A method of synchronizing a plurality of computing 
devices according to claim 1 , wherein step d) is preceded by 
the step of attempting synchronization of said computing 
devices based upon said respective further version number 
of each of said plurality of computing devices. 

12. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein one of said version 
numbers is maintained both locally to a respective comput- 
ing node and remotely therefrom, and wherein said locally 
and remotely maintained one of said version numbers are 
compared to determine if a conflict exists. 

13. A method of synchronizing a plurality of computing 
devices according to claim 7, wherein garbage collection 
includes the steps of: 

a) notifying each of said devices to delete said record; 

b) notifying each of said devices that each of said devices 
has successfully been notified to delete said record; and 

c) notifying each of said devices that step b) has been 
successfully completed. 

14. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein said maximum size 
for each of said computing devices is different. 

15. A method of synchronizing a plurality of computing 
devices according to claim I, wherein said maximum value 
is an integer. 

16. A computing device, one of a plurality of computing 
devices, having a database replica, said database replica 
comprising a plurality of records, said computing device 
comprising: 

request means for providing a synchronization request to 
a farther computing device having a further database 
replica comprised of a further plurality of records; 

version tabic means for maintaining version numbers for 
each of said plurality of records, said version numbers 
each having a maximum size, in bits; 

version number manager means for configuring said 
maximum size, said maximum size separately config- 
urable for each of said computing devices; and 

synchronization means for synchronizing said plurality of 
records with said further plurality of records based 
upon said version numbers. 

17. A computing device according to claim 16, wherein 
said version numbers are integers. 

18. A computing device, one of a plurality of computing 
devices, having a database replica, said database replica 
comprising a plurality of records, said computing device 
comprising: 

request means for providing a synchronization request 
Ixitwccn said computing devices; 

version table means for maintaining version numbers for 
each of said plurality of records in each of said com- 
puting devices, said version numbers each having a 
maximum size, in bits; 

version number manager means for configuring said 
maximum size, said maximum size separately config- 
urable for each of said computing devices; and 

synchronization means for synchronizing said plurality of 
records in each of said computing devices based upon 
said version numbers. 

19. A plurality of computing devices according to claim 
18, wherein said maximum size for each of said computing 
devices Ls different. 

20. A plurality of computing devices according to claim 
18, wherein said version numbers for a first of said com- 
puting devices is maintained in a first list and said version 
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numbers for a second of said computing devices Ls main- 
tained in a second list. 

21. A plurality of computing devices according to claim 
20, wherein said first list and said second list indicate 
respective records which correspond and are dilTcrcnt 5 
vcrsioas, and, during synchronizing, at least one of said first 
of said computing devices and said second of said comput- 
ing devices arc updated so that the first of said computing 
devices and the second of said computing devices have 
respective records which correspond and have the same 10 
versions. 

22. A plurality of computing devices according to claim 
20, wherein during synchronizing at least one of said first list 
and said second list are updated so that said first list and said 
second list indicate respective records which correspond to 15 
each other. 

23. A plurality of computing devices according to claim 
18, wherein a respective one of said version numbers is 
incremented when a respective one of said devices updates 

a respective one of said records during synchronizing. 20 

24. A plurality of computing devices according to claim 
20, wherein during synchronizing, one of said records is 
deleted from one of said first of said computing devices and 
said second of said computing devices so that the first of said 
computing devices and the second of said computing 25 
devices have the same corresponding records. 

25. A plurality of computing devices according to claim 
23, wherein if said respective one of said version numbers 
is incremented to a maximum value, then a new record is 
created and said respective one of said records is deleted. 30 

26. An article of manufacture comprising a computer 
useable medium having computer readable code means 
embodied thereon for synchronizing a plurality of comput- 
ing devices each containing respective database replicas, 
each of said replicas having respective records, the computer 35 
readable program code means in said article of manufacture 
comprising computer readable program code me a as for 
causing a computer to effect: 

a) configuring a maximum size, in bits, for a version 
number, said maximum size separately configurable for 40 
each of said computing devices; 

b) maintaining, for each of said computing devices, said 
version numbers for each of said respective records, 
said version numbers having said maximum size; 

c) transmitting a synchronization request between said 
computing devices; and 

d) synchronizing said computing devices so that said 
respective data base replicas have common records 
based upon said version numbers respectively main- 5() 
tained for said computing devices. 

27. An article of manufacture as recited in claim 26, the 
computer readable program means in said article of manu- 
facture further comprising computer readable program 
means for causing a computer to effect maintenance of said 
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version numbers for a first of said computing devices in a 
first list and said version numbers for a second of said 
computing devices in a second list. 

28. An article of manufacture as recited in claim 27, 
wherein said first list and said second list indicate respective 
records which correspond and arc dilTcrcnt versions, the 
computer readable program code means in said article of 
manufacture further comprising computer readable program 
means for causing a computer to effect updating of said 
second of said computing devices so that the first of said 
computing devices in the said second of computing devices 
have respective records which correspond and have the same 
versions during synchronizing. 

29. A program storage device readable by machine, tan- 
gibly embodying a program of instructions executable by the 
machine to perform method steps for synchronizing a plu- 
rality of computing devices each containing respective data- 
base replicas, each of said replicas having respective 
records, said method comprising the steps of: 

a) configuring a maximum size, in bits, for a version 
number* said maximum size separately configurable for 
each of said computing devices; 

b) maintaining, for each of said computing devices, said 
version numbers for each of said respective records, 
said version numbers having said maximum size; 

c) transmitting a synchronization request between said 
computing devices; and 

d) synchronizing said computing devices so that said 
respective data base replicas have common records 
based upon said version numbers respectively main- 
tained for said computing devices. 

30. A program storing device as recited in claim 29, 
wherein said version numbers for a first of said computing 
devices is maintained in a first list and said version numbers 
for a second of said computing devices is maintained in a 
second list. 

31. A program storing device as recited in claim 30, 
wherein said first list and said second list indicate respective 
records which correspond and are different versions, and, 
during synchronizing, at least one of said first of said 
computing devices and said second of said computing 
devices are updated so that the first of said computing 
devices and the second of said computing devices have 
respective records which correspond and have the same 
versions. 

32. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein at least one of said 
computing devices is a hand held device. 

33. A plurality of computing devices according to claim 
18, wherein at least one of said computing devices is a hand 
held device. 
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